Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Perform a Postmortem

An important but often neglected part of development is a thorough dissection of the project after its completion. You can learn a lot from the bugs encountered during development, but only if you pay close attention. Making mistakes does not automatically make you wiser. You must study the errors carefully to learn from them.

During this postmortem analysis, you should determine why things went wrong and how they were fixed. Using that information, you can hopefully make fewer mistakes in the future. The following list summarizes questions you should ask about each bug.

What was the bug? Be sure you understand what the bug was.

At what stage in project development was the bug introduced? It is a well-known fact that the longer a bug remains in a project, the harder it is to fix. Pay special attention to bugs introduced during the design phase and other early stages.

Who caused the bug? You do not need to be judgmental about this, but you need to find out who caused the bug. Someone who caused a large number of bugs might benefit from some extra training. If someone proves better at one aspect of the project than another, he might concentrate on that area. For example, some people are great at high-level design and documentation but weak at coding. Use everyone’s strengths in the future.

When and how was the bug detected? Can that method of detection be used intentionally to look for similar errors in the future? You may be able to use the method to devise new tests to catch similar bugs earlier.

Could the bug have been detected sooner? If you can figure out ways to find similar bugs sooner, you can use them to improve tests and increase early detection.

How could the bug have been prevented in the first place? The easiest bugs to fix are those that do not occur. If you can think of ways to make the bug less likely to occur, use them in the future. This does not include statements like, “Pay better attention to detail.” Answers must be concrete to be useful. For example, “Finalize database design before designing user management module.”

Of course, not all of this information will be available at the end of the project unless you do a little bookkeeping during development. If a bug was introduced during design and fixed during early development, no one may remember it by the time the project is finished.

Developers should keep track of the bugs as they are found and fixed. The process must be easy enough that it does not become a burden to the developers. Otherwise, they may not bother to record the bugs, or their productivity will suffer.

To minimize the amount of extra work required, developers should record only bugs that make it into the project’s master code. A bug that a developer writes into a new subroutine and then immediately fixes does not count.

The developer should record the minimum amount of information needed to analyze the bug later. This includes where the bug is located, its description, and when it was detected. For example:

Knowing the module and routine that contains the bug, you can probably deduce who caused the bug and when, even at the end of the project.

Gather this information and study it. Pay special attention to bugs that took a long time to detect or fix. Share your results with other projects. You may not be able to prevent every problem from reoccurring in another project, but you guarantee problems if you refuse to learn from past mistakes.

Self-Test

Because testing is a bit different from the topics covered in previous chapters, this section does not present source code for you to evaluate. Instead, it describes an application for you to test. Figure 14.7 shows a simple calculator program named Calc. This program allows the user to enter numbers with up to 12 characters including a decimal point, plus an optional negative sign. The user can click on the buttons to perform simple arithmetic calculations. In addition to clicking buttons, the user can enter values and operators using the keyboard.

The program displays the result of the calculation if the result will fit in 12 characters. If the result is too large, the program displays the string Overflow. If the value is too large a negative number, the program displays Underflow. If the user tries to divide by 0, the program displays #INF.

For this self-test, design a set of black box tests for this program. Because you do not know how the application works internally, you cannot build white box tests. However, knowing the program’s specification, you can probably create a set of gray box tests that search for strange special cases that might give the program trouble. For example, these tests should divide by 0, cause an overflow and underflow, and so forth.

Figure 14.7  The Calc program.

Write the tests in English. There is little point in writing tests in Visual Basic code until you have looked at the program’s source code. Appendix A, “Self-Test Solutions,” contains a description of tests used to find bugs in this program. You can find the source code for the program including its tests at the book’s Web site at www.vb-helper.com/err.htm.